Here a comparison of the xy trajectories between ideal circular arcs and the HL commander segments from the current implementation:

90 degrees

180 degrees

360 degrees

@whoenig or @jpreiss. Do you have time to pitch in on this functionality? It goes with the cflib (see this PR bitcraze/crazyflie-lib-python#470) but this would also require a change in the cpp link in crazyswarm2 then as well

The current build issues is because of the cflib not being up to date, but this is a bit of an API breaking change (or rather crtp). Wonder if it might be better to make this another type of message? Let's wait to see what the others say.

Generally, CRTP breaking changes are not allowed. We can add a new message and deprecate the old one (and eventually remove the old one). Any (CRTP) API change should also bump up the "protocol version", so that clients can easily know which functionality might be available.

Otherwise I do like these additional features, of course!

Thanks for the quick pre-review!
Ok, so I will introduce a GOTO2 instead

So I added a GOTO2 while keeping GOTO in the firmware.

Tested on a crazyflie 2.1

• with old cfclib (crtpCommanderHighLevelGoTo, current master)
• and with updated cfclib (crtpCommanderHighLevelGoTo2, Improved HL commander - spiral & linear segment crazyflie-lib-python#470)

Also increased the CRTP protocol version by 1.

What is the policy with deprecation/removal, i.e. how long do we keep the deprecated message?

Our current policy about depreciation would be depreciate messages for at least one version before dropping it. The intent is that if a client is developed for version n it should work on version n+1. We have never really used this rule though and the python client is not (yet) checking this version. So I would depreciate packets only if the old packet existence really causes a problem.

Thanks for the review and for testing this @gemenerik!

One downside is that the spiral definition feels a bit unintuitive. Users need to calculate to know where the drone will end up, and it may take some playing around - or looking at your drawings - to see what parameters must be changed to achieve the desired arc.

Yes, I agree it is not very intuitive... I wanted to fit all the parameters into one message, so the size limit made me reduce the number of parameters.... the result is that the definition is relative to the current setpoint...

So you may need to do a bit of math, but in practice, we typically use 90- or 180-degree segments, often in a loop with multiple iterations, and so the calculation of the final position is not so difficult...

What happens with angles greater than 2π? It seems to work but can behave unpredictably, what should happen?

Actually, I have not tried this :)
We can limit the angle to +/-2pi as I don't think there is much of a use to go beyond that...

What about negative radii? I had initially thought that a positive and negative radius might create an S-curve, which may not be a fair expectation. I also noticed that setting both radii to negative values appears to cause the drone to fly backwards.

Again, one thing I have not tested :)
While a combination of positive and negative radiuses can produce some interesting shapes, let's allow only positive values to make the result predictable...
To fly backward, a negative angle can be used.

Agree with the vertical/tilted spiral, it was one thing I initially considered, but decided to leave that for later as we didn´t have an urgent need for it :) Also, this would require an additional set of parameters to define the axis of rotation... So now, that is always z axis...

So you may need to do a bit of math, but in practice, we typically use 90- or 180-degree segments, often in a loop with multiple iterations, and so the calculation of the final position is not so difficult...

Fair point!

Actually, I have not tried this :) We can limit the angle to +/-2pi as I don't think there is much of a use to go beyond that...
...
Again, one thing I have not tested :) While a combination of positive and negative radiuses can produce some interesting shapes, let's allow only positive values to make the result predictable... To fly backward, a negative angle can be used.

I agree, let's limit to +/-2pi and positive radii. Then together with the minor comments above it's good for merging as far as I'm concerned.

Agree with the vertical/tilted spiral, it was one thing I initially considered, but decided to leave that for later as we didn´t have an urgent need for it :) Also, this would require an additional set of parameters to define the axis of rotation... So now, that is always z axis...

OK something to keep in mind for the future!

All should be implemented, flight tested successfully